The present application is related to future radio networks, especially base stations (Macro, Pico and Femto) and the respective mobile backhaul. It covers following technology fields:                network sharing, RAN sharing        network virtualization        
Currently, cloud computing, network sharing and network virtualization is one of the hottest topics for service, transport and access providers. In this context virtualization and virtualization technologies are to be seen as enabler for cloud services and network sharing.
Meanwhile, sharing of transport resources (i.e. multiple service providers share the physical resources of one or several transport providers) is already becoming reality and products are available, the next logical step is virtualization of access resources—fixed and mobile. Current solutions for sharing RAN resources like GWCN, MOCN and MORAN (see below) are deficient since they require tight interworking of operators—excluding business models that allow sharing with sharing operators being agnostic of one another, especially those cases, where one operator serves as access provider for a multitude of third party operators. There is more and more demand for this kind of solutions, sometimes operator driven, sometimes driven by regulators.
FIG. 1 shows the principle architecture of a 4th generation mobile network. Terminals (UE) are connected via the RAN (radio access network), comprising of eNodeB base stations through an EPC (evolved packet core) to service endpoints in the SDN (service delivery network) which most often is represented by server farms where content and services are stored/made available for UE access. In the context of this invention, an SDN shall represent an MNO services network, but also services networks of third party service providers, or even the internet. The evolved packet core mainly comprises of a mobility management entity (MME) acting as central control unit for the Radio Access Network (RAN) and gateways, namely serving gateways S-GW which mediate UE traffic from the base stations towards packet data gateways P-GW which act as transition point to SDN or other networks. The involvement of eNodeB, S-GW and P-GW is to a certain extend steered by the mobility management entity (MME).
Besides the E2E data which shall be exchanged between both peer ends (UE/SDN), denoted as U-plane further on, there is a significant exchange of mobile network control messages between nodes of the mobile network, which are not necessarily related to the services themselves (payload) but which are necessary to run an E2E service delivery. This information exchange, denoted as C-plane further on, comprises e.g. measurement reports from the UE to eNodeB and mobility management entities (MME), user/service related information between UE and a packet data gateway (P-GW), tunnel setup information between serving gateways (S-GW) and P-GW, user authentication and authorization between home subscriber systems/home location registers (HSS/HLR) and a variety of nodes. Note that this information shall not be mistaken with control messages between services and user devices (like hypertext transfer protocol (HTTP) or file transfer protocol (FTP)) and that this information is in no way related to control messages of underlying transport nodes. In the figure, nodes having control functionality are indicated with a C-triangle, those having data forwarding functionality are marked with a D-circle, and of course, some nodes have both functionalities.
With respect to transport, there is most often a clear separation of RAN and EPC. Base stations are in remote areas in rural scenarios and densely co-located in urban areas and, thus, operators have to cooperate (sites) and often have to rely on 3rd party transport since they do not own a transport network (e.g. in rural areas). Thus, RAN transport covers the transport domains of access (passive optical network (PON)/next generation optical access (NGOA)), Metro (e.g. carrier Ethernet (CET)). Most often, RAN traffic is fed into a DWDM long haul network with (quite some) optical cross connects and then conveyed further on to the services networks, which could be Metro-like connected. Most often, on higher transport layers, eNodeB connections base on internet protocol (IP) or Ethernet, the EPC run on IP/MPLS (MPLS: Multiprotocol Label Switching). It should be noted, that the higher layer mobile network architecture typically is—to a certain extend—taking into account the disruptiveness in the underlying transport, e.g. nodes are placed at typical transition areas.
When making physical resources such as transport capacity abstractly available to higher layers (virtualization), there are some new emerging networking technologies available that are promising candidates for realization. One of these is defined in the OpenFlow consortium (www.openflow,org).
The basic idea is to (re)use commercial-off-the-shelf routing and switching platforms. In a simplified view, those already comprise of facilities (see FIG. 2) for data path handling (e.g. switching matrix), software and flow tables, which define how data packets are handled (routed, switched) depending e.g. on the information that is contained in the packet headers. A simple rule could for example mean that incoming packets on port 0 will be forwarded to port 2 if the destination address found in the header can be resolved and to port 3 otherwise.
The idea of OpenFlow is that the flow tables may be manipulated from outside via an API (OpenFlow interface) and that a control instance can slice different resources and present those, or a subset of those, to further control instances outside the box (FlowVisor). This way an application can manipulate resources of e.g. one or several Ethernet switch(es) by manipulating a flow table which is presented by an instance which could be a switch or a FlowVisor instance hiding a hierarchical structure comprising of switches and/or FlowVisor controllers. This way the application doesn't need to have the knowledge of whether its access to resources directly affects one switch or several switches which are hierarchical organized.
3rd generation partnership project (3GPP) technical report TR 22.951 defines the service aspects and requirements for network sharing. The common 3GPP architecture, which consists of a Radio Access Network RAN and a Core Network CN has been extended as shown in FIG. 3 to support multiple sharing scenarios.
This flexibility is needed to allow Mobile Network Operators (MNO) to adapt to regulations given by the national authorities (e.g. to prohibit national roaming). There are four possible basic sharing scenarios:                Multi Operator Radio Access Network (MORAN) (Site Sharing): MORAN can be seen as a classical site sharing which uses a single physical Base Station to support logically independent Base Stations with separated spectrum, one for each MNO;        Roaming (national and international): Roaming is operated with the spectrum of that MNO who owns the RAN (visited network). This MNO allows the subscribers of other MNOs (home network) to use its mobile resources according to specific roaming agreements;        Multi Operator Core Network (MOCN): MOCN configurations share the RAN of one MNO with several other MNOs. The core networks of the MNOs are directly connected to that RAN; and        Gateway Core Network (GWCN): GWCN configurations share the RAN and core network elements of one MNO with several other MNOs.        
Although network sharing and virtualization techniques are not new topics, they require that Mobile Network Operators which want to cooperate in these fields have to work closely together on regulatory, commercial and technical level. In general, a quite complex part is related to the huge number of technical details that need to be agreed between the involved MNOs (e.g. network addresses, firewall configurations, closed subscriber group identities (CSG-Ids), cell broadcasts, unique tracking area codes, security parameters, etc.).
The following example describes a typical problem based on PLMN-ID configuration for multiple MNOs in a shared radio access network (RAN). This problem is basically similar for other parameters which are used in sharing environments and/or network virtualization scenarios.
3GPP has defined in technical specification TS 23.251 two basic network sharing architectures, which allow different core network operators to connect to a shared radio access network:                Gateway Core Network (GWCN) configuration        Multi-Operator Core Network (MOCN) configuration        
In the latter architecture only the radio access network RAN is shared while in the first architecture RAN and core network elements SGSN/MSC (alternatively MME/S-GW in case of EPC) are shared.
In case of RAN sharing by multiple MNOs the system information broadcast in a shared cell contains the public land mobile network identification (PLMN-ID) of each operator and a single tracking area code (TAC) valid for all involved MNOs.
The configuration of a shared network is hidden to the UE, i.e. the UE behaviour in both configurations is identical. When the UE tries to connect to the Mobile Network (RAN and CN), it has to perform the 3GPP defined procedures. These procedures are defined in a way that each UE is connected to the corresponding CN of its Mobile Operator based on the selected PLMN-ID received in the cell broadcast. This mechanism requires that a shared RAN is able to broadcast multiple PLMN-IDs, one for each involved MNO. 3GPP has introduced the “equivalent PLMN-ID” feature to support this functionality. As of today broadcast parameters are configured in the RAN via an OAM system which belongs to the MNO owning the RAN.
The other MNOs are not able to configure their parameters directly. They have to request their configuration needs offline or via higher management interfaces from the RAN Operator. A solution that allows multiple MNOs to manage the shared RAN is not feasible without further measures because the PLMN-ID is stored in a list with the other PLMN-IDs and there is a high risk that an MNO overwrites configuration parameters of another MNO and vice versa.
The additional measures required for the OAM-parameter-configuration-access for several MNOs increase with higher level of OAM automation. For example a fully automated interface has to provide a basic functionality for authentication, authorization, transaction security and overwrite protection but also additional functions like translation, adaptation and activation mechanisms which depend on the needed parameter sets and their vendor specific meaning.
FIG. 4 shows a principle architecture that could be used to enable two operators (PLMN 1, PLMN 2) to use eNodeBs of PLMN A in the same way as they use eNodeBs of their network, i.e.                they use their PLMN OAM for configuration;        they equip PLMN A eNodeB with identities that are suitable for their PLMN; and        they configure PLMN A eNodeB in a way that terminals (UE1, UE2) are served in the same way as they are served in their PLMN.        
Thus, the PLMN-A eNodeB would have to serve three networks, allowing OAM, C-Plane and U-Plane for three separate networks.
As discussed above, today's eNodeBs cannot cope with such a scenario without additional measures—there is a need to coordinate resource usage, to cope with contradicting OAM commands and so forth.
A simple but well established method is the offline exchange or exchange via higher management interfaces of configuration parameters (e.g. eMail, request forms, work order requests, . . . ). In case of the PLMN-ID, for example, the MNO provides the necessary PLMN-ID parameter for his CN to the RAN operator. The RAN operator then configures this PLMN-ID as equivalent PLMN-ID to the shared RAN. Of course there are solutions to automate this process outside of 3GPP standardization, but all these solutions are more or less proprietary and require a case by case integration solution. The disadvantages of existing solutions are obvious:                complex and expensive integration of OAM procedures        no standardized solution to guarantee easy re-use of such integration solutions        manifold interfaces with slow and lengthy test periods        